18장. EC2 요금 모델 — On-Demand · Spot · RI · Savings Plans
이 장에서 말하고자 하는 것
EC2를 띄울 때 똑같이 t3.small을 띄워도
어떤 요금 모델로 구매하느냐 에 따라 비용이 크게 달라진다.
네 가지 주요 모델:
- On-Demand
- Spot
- Reserved Instance (RI)
- Savings Plans
같은 사양에 최대 90% 까지 비용 차이가 나기도 한다.
이 장은 각자의 자리와 운영적 선택을 정리한다.
1. On-Demand — 기본값
시간당 (또는 초당) 사용한 만큼 청구
약정 없음 / 자유로움
가장 비쌈 (기준 가격)
- 시작 / 실험에 가장 자연스러움
- 트래픽 예측 어려운 초기 단계
- 단기적이거나 들쭉날쭉한 워크로드
운영 초기는 거의 항상 On-Demand로 시작
2. Spot — 가장 싸지만 잠깐 끊김
AWS의 남는 용량을 경매처럼 빌려 쓴다.
On-Demand 대비 약 70~90% 저렴
AWS가 필요할 때 회수 (2분 전 알림)
Spot이 어울리는 경우
- 상태 비저장 워커
- 배치 / ML 학습
- CI 빌드 노드
- Auto Scaling 그룹의 일부
Spot이 어울리지 않는 경우
- 데이터베이스
- 상태 보존 중요한 단독 인스턴스
- 회수가 비즈니스에 즉시 영향 주는 워크로드
회수돼도 자동 복구되는 워크로드만 Spot
3. Reserved Instance (RI) — 약정 할인
1년 또는 3년 약정 → 약 30~70% 할인
선납 / 부분 선납 / 미선납 옵션
인스턴스 타입 · 리전 · OS 지정 필요
특징:
- 약정 기간 동안 그만큼의 컴퓨트를 늘 쓰는 게 전제
- 인스턴스 타입이 바뀌면 옛 RI가 무용지물이 되기도 함
- “어떤 사양이 얼마나 필요한가” 가 명확할 때 유리
RI는 점점 자리를 Savings Plans 에 내주고 있다
4. Savings Plans — 더 유연한 약정
RI의 진화형. 같은 1/3년 약정이지만 더 유연하다.
Compute Savings Plans
- “시간당 $X 만큼은 무조건 쓴다” 약정
- EC2 · Fargate · Lambda 모두 적용
- 인스턴스 패밀리 · 리전 자유롭게 바꿔도 할인 유지
- 가장 유연
EC2 Instance Savings Plans
- 특정 인스턴스 패밀리에 더 큰 할인
- 유연성은 RI 수준
새 약정은 거의 항상 Compute Savings Plans 가 정답
5. 네 모델을 한 표로
| 모델 | 약정 | 할인폭 | 회수 위험 | 유연성 |
|---|---|---|---|---|
| On-Demand | 없음 | 기준 | 없음 | 매우 높음 |
| Spot | 없음 | 70~90% | 있음 (2분 알림) | 높음 |
| RI | 1/3년 | 30~70% | 없음 | 낮음 |
| Compute Savings Plans | 1/3년 | 30~70% | 없음 | 높음 |
6. 어떻게 조합할까 — 운영 전략
대부분의 운영은 혼합 전략 을 쓴다.
기본 안정 운영 (24시간 늘 떠 있어야 하는 부분)
→ Compute Savings Plans
피크 시간 추가 / 스케일 아웃
→ On-Demand
상태 비저장 워커 / 배치
→ Spot
특정 인스턴스 패밀리 큰 사용
→ EC2 Instance Savings Plans
Fargate에도 똑같이 적용
Fargate : Compute Savings Plans 할인 가능
Fargate Spot : 70% 수준 할인 (Spot 동일 회수 가능)
우리 척추(ECS Fargate)에서는 Fargate + Fargate Spot 혼합이 표준
7. 데이터 전송 비용 — 의외의 폭탄
EC2 컴퓨트만 보다가 청구서가 늘어나는 가장 큰 이유는 보통 데이터 송신 이다.
인터넷으로 나가는 트래픽: GB당 과금
NAT Gateway 통과: 시간 + GB당
Cross-AZ: 작지만 누적
Cross-Region: 크다
대응:
- CloudFront로 흡수 (CloudFront → 사용자는 더 쌈)
- VPC Endpoint로 NAT 우회 (88장)
- 같은 AZ로 묶기 (가능한 곳만 — 가용성과 균형)
8. 비용 가시화 — Cost Explorer · CUR
운영의 시작은 “보는 것” 이다.
Cost Explorer : 그래프로 비용 추세
Cost and Usage Report (CUR) : 자세한 데이터를 S3로 → Athena
Budgets : 예산 임계 알람
매주 한 번 Cost Explorer 보는 습관
9. 우리 서비스에서
ECS Fargate (web · api · workers)
→ Compute Savings Plans 70% 약정
→ 워커 일부는 Fargate Spot
RDS · ElastiCache
→ RI 또는 Aurora I/O Optimized 옵션
S3 / DynamoDB / Lambda
→ Compute Savings Plans 가 일부 적용 (Lambda)
→ 자체 수명 주기 · TTL · On-Demand 로 시작
비용 가드:
Budgets 알람 (월 임계 80% · 100%)
Cost Anomaly Detection
태그로 서비스별 비용 추적
10. 직접 확인해보기 — CLI · 콘솔
Cost Explorer로 한 달 비용
콘솔: Billing & Cost Management → Cost Explorer
예산 알람 만들기
aws budgets create-budget \
--account-id <acct> \
--budget '{
"BudgetName":"monthly-200",
"BudgetLimit":{"Amount":"200","Unit":"USD"},
"TimeUnit":"MONTHLY",
"BudgetType":"COST"
}' \
--notifications-with-subscribers ...
Savings Plans 추천 보기
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years ONE_YEAR \
--payment-option NO_UPFRONT
추천 결과는 참고용 — 약정 전에는 사용 패턴을 본인이 한 번 더 확인한다
11. 코드로는 이렇게 생겼다 — Terraform (Budget · Anomaly)
resource "aws_budgets_budget" "monthly" {
name = "monthly-prod"
budget_type = "COST"
limit_amount = "500"
limit_unit = "USD"
time_unit = "MONTHLY"
notification {
comparison_operator = "GREATER_THAN"
threshold = 80
threshold_type = "PERCENTAGE"
notification_type = "ACTUAL"
subscriber_email_addresses = ["ops@example.com"]
}
}
resource "aws_ce_anomaly_monitor" "service" {
name = "service-anomaly"
monitor_type = "DIMENSIONAL"
monitor_dimension = "SERVICE"
}
resource "aws_ce_anomaly_subscription" "alerts" {
name = "anomaly-alerts"
monitor_arn_list = [aws_ce_anomaly_monitor.service.arn]
frequency = "DAILY"
subscriber {
type = "EMAIL"
address = "ops@example.com"
}
}
예산 + 이상 감지 두 가지가 비용 통제의 출발선.
12. 이렇게 쓰면 망한다 — 안티패턴
안티패턴 1. 처음부터 큰 RI 약정
사용 패턴이 안 잡힌 상태에서 3년 약정 → 안 쓰는 RI 잔뜩.
On-Demand로 3~6개월 돌리고 데이터로 약정
안티패턴 2. 상태 있는 서비스에 Spot
회수 시 데이터 손실 또는 서비스 중단.
안티패턴 3. NAT Gateway 비용을 못 본다
조용히 매달 늘어난다.
S3 · ECR 등은 VPC Endpoint로 우회
안티패턴 4. 태그 없이 운영
어느 서비스가 얼마를 쓰는지 모름 → 최적화 불가능.
Environment · Service · Team 태그는 사실상 필수
13. 한 줄로 정리
같은 사양도 어떻게 사느냐에 따라 비용이 90%까지 달라진다.
안정 부하는 Savings Plans, 상태 비저장은 Spot, 변동은 On-Demand — 혼합이 정답이다.
14. 이 장의 핵심 정리
- On-Demand · Spot · RI · Savings Plans 네 모델이 있다.
- 새 약정은 Compute Savings Plans 가 거의 항상 정답이다.
- Spot은 상태 비저장 워크로드에만 — Fargate Spot도 마찬가지.
- 데이터 전송 · NAT Gateway 가 의외의 비용 폭탄.
- Budgets · Cost Anomaly Detection · 태그로 가시화.
- 약정은 데이터로 — 사용 패턴 잡힌 후에 결정한다.